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REMARKS/ARGUMENTS 



Claims 1-22 remain in the application, all of which stand rejected. 



1. Rejection of Claims 1-22 Under 35 USC 102(e) 

Claims 1-22 stand rejected under 35 USC 102(e) as being anticipated by 
Bennett et al. (U.S. Pat. No. 6,799,21 1 B1; hereinafter "Bennett"). 

Regarding claim 1, the Examiner asserts, in part, that: 

. . .Bennett discloses. . . 

determining whether a device interface for each of said 
plurality of devices conforms with a standard interface [Bennett, 
Interpretation/extraction module, col 4 lines 40-65]; 

translating said device interface to conform with said 
standard interface when said device interface is nonconforming 
[Bennett, convert non-standard data into standard interface module, 
col 5 lines 7-28, Fig 1-2]; 

6/17/2005 Office Action, sec. 4, p. 2. 

Applicant respectfully disagrees. The portions of Bennett that the Examiner 
relies on in making the above assertion state: 

Interpretation/extraction module 110 takes as inputs the non-standard 
data received from the communications modules 108 that attach to it. 
Interpretation/extraction module 110 can parse such non-standard data or 
particular data that may be used for network management purposes (e.g., 
management data). Additionally, interpretation/extraction module 110 may 
incorporate business and/or system rules, filters, correlation logic, rate logic, 
persist logic, etc. which can be applied to data received from communication 
modules 108. For example, interpretation/extraction module 110 may be 
configured with logic to examine and parse non-standard data for particular 
strings of text/data and to extract the same when found. 

Interpretation/extraction module performs a useful function to filter out 
unnecessary data from source systems 102 from which network management 
data (in non-standard form) originates and which passes through 
communication modules 108. Hence interpretation/extraction module 110 can 
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reduce traffic and improve system performance of network management 
systems. It is important to note however, that a common communication agent 
provided in accordance with the present invention does not require the 
implementation of such rules and filters, and an organization implementing a 
common communications agent in accordance with the present invention may 
choose not to implement parsers, rules functions, etc. 

Bennett, col. 4, lines 40-65. 



After management data has been extracted from the source data 
received via communication modules 108, such management data may then 
be passed on to standard interface module 112. The standard interface 
module 1 12 is the module where non-standard data is converted into 
standardized data and ultimately passed to a network management/monitoring 
system. Like other modules within a common communication agent provided 
in accordance with the present invention, there can be multiple instances of a 
standard interface module 112, whereby each such module may receive data 
from different interpretation/rules modules 110. Standard interface module 
1 1 2 takes the data generated and transmitted from the interpretations/ 
extraction module 110 and converts such data into standardized data having a 
standard format such as one provided in accordance with SNMP (Simple 
Network Management Protocol), CMIP, IDL (Interface Definition Language 
such as COBRA), etc. A standard interface module provided in accordance 
with the present invention is flexible enough to convert data from the 
interpretation/extraction module 110 into a format that may be defined by the 
organization implementing the present invention. 

Bennett, col. 5, lines 7-28. 

Bennett's above disclosure talks about "interpretation", "extraction" and 
"conversion" of data. Applicant therefore believes the above disclosure is directed 
toward the final element of Applicant's claim 1, which recites, "managing said number 
of devices according to said standard interface." However, the first two elements of 
Applicant's claim 1 are not directed to device management, but are rather directed to 
the setup of a system for managing devices. As such, these first two elements are 
largely interface-driven (i.e., it is determined whether device interfaces are 
conforming and, if not, device interfaces are translated - no data needs to be flowing 
as these system setup steps are performed). 

In the end, Bennett's system enables management of network devices 102 via 
a standard interface 112, which does bear some similarly to the last element of 
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Applicant's claim 1 . However, Bennett is largely silent on how the communication 
modules 108, interpolation/extraction module 110 and standard interface module 112 
(i.e., those modules that are used for device management) are initially setup and 
configured. In fact, to a large degree, one can only speculate on how Bennett's 
modules 108, 110 and 112 are setup and configured. It appears to Applicant, 
however, that Bennett does not "determine] whether a device interface for each of 
said number of devices conforms with a standard interface" and then "translate] said 
device interface to conform with said standard interface when said device interface is 
nonconforming". Rather, it seems that Bennett's system does not care which device 
interface a particular piece of data comes from. Bennett then generates the standard 
data 1 14 by parsing non-standard data for recognizable strings and/or the like. For 
example, in the above excerpts from Bennett, Bennett indicates that, 
"interpretation/extraction module 110 may be configured with logic to examine and 
parse non-standard data for particular strings of text/data and to extract the same 
when found." This method is very much data-driven, and does not appear to 
contemplate a previous setup or configuration of particular translators for particular 
device interfaces. On the other hand, Applicant's claim 1 first determines "whether a 
device interface for each of said number of devices conforms with a standard 
interface", and then translates "said device interface to conform with said standard 
interface when said device interface is nonconforming". Thus, it is not "data" that is 
being translated in the first two elements of Applicant's claim 1 , but rather 
"interfaces". 

Although the method of Applicant's claim 1 might be useful in Bennett's 
system, Bennett does not suggest this. In fact, and as previously noted, Bennett 
provides few (if any) details on how the systems shown in its FIGS. 1 & 2 are setup 
and configured. Applicant's claim 1 is therefore believed to be allowable over 
Bennett's teachings. 

Applicant's claims 9 and 19 are believed to be allowable at least for reasons 
similar to why claim 1 is believed to be allowable. Applicant's claims 2-8, 19-18 and 
20-22 are believed to be allowable at least for the reason that each of these claims 
depends from one of claims 1 , 9 or 19. 
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2. Conclusion 



Given the above Remarks, Applicant respectfully requests the timely issuance 
of a Notice of Allowance. 



Respectfully submitted, 
DAHL & OSTERLOTH, L.LP. 




Gregory W. Osterloth 
Reg. No. 36,232 
Tel: (303)291-3200 
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